這幾天紀錄下開發流程中可能會考量的項目跟使用工具紀錄, 在開發完成到系統交付之後, 又是另一個階段的開始。
當每個系統都只是微服務底下的一環, 要怎麼知道我交出了一個有品質的系統呢？
大概有幾項可以作為參考：

• OnCall 次數
  以我們團隊的現況來說, 服務都是在K8s上面運作, 團隊中的成員兩兩一組, 每週有兩位值日生負責當週值班來處理問題。在微服務底下, 每個成員手上都會有多個系統在運作, 一開始上線通常都是手忙腳亂、全員備戰的狀態,被Call的次數可能也很頻繁, 各種未預期的狀況會如雨後春筍般的接踵而來
  但經過一段時間之後(大約6個月), 接到電話的次數就應該要慢慢地減少, 這就是系統開始穩定的一種參考依據。

• 臨時維護次數
  臨時維護是指在非正常維護期間需要掛上系統維護緊急修復功能的時候。通常這時候是發現重大瑕疵, 必須要馬上修復的情況, 除了修正程式, 可能還需要大量修正舊資料, 系統上線後都會遇上幾次, 那也是一個兵荒馬亂
  同樣地, 在上線一段時間之後, 臨時維護的次數也應該要變少, 表示每個系統都在預期內穩定的運作著。

• K8s上服務存活的時間
  k8s上面可以看到每個服務最近一次重啟之後的的運行時間。我們的正常維護週期為14天, 每個維護日可以更新功能和修正bug, 有些系統會在上線前進行燒機測試, 要確保它無論如何都要能撐過14天不會重啟。所以在K8s上的存活時間可以用來判斷系統被異動的次數是否很頻繁, 頻繁被異動的系統同時也存在著風險, 這也可以作為一個參考。

• Error Log 數量
  我們的系統Log都會透過ELK集中收集起來, 而Log等級大於Warning的則會被發送到Telegram工作窗。系統會發生Error的情況大多會在測試階段被發現, 但還是會存在漏網之魚, 隨著系統上線後逐步地補強漁網讓系統趨近穩定, Telegram跳警報的次數也會隨著慢慢變少, 手機越來越安靜, 也是判斷系統穩定的一種參考值

• Bug數量
  這是檢視個人交付的系統品質的指標, 系統bug大多是在開發系統的過程中未注意到的情況, bug可以透過各種測試方式來減少在交付後才發生的狀況, 像是TDD、BDD等各種測試方法都是輔助工程師檢視專案品質的工具。回歸到系統本質上去檢視, bug越少的系統也會相對的穩定一些, 所以它也可以做為系統是否穩定的參考值。

今天大約分享幾個檢視系統是否穩定的參考值, 一個有品質的系統或專案不會只是一個點做好做滿就可以達成的, 而是需要每個環節去反覆的檢視跟調整, 系統會隨著時間而日趨成熟跟穩定, 穩定的系統或許就可以稱其為一個有品質的系統, 一個有品質的系統才能讓工程師享受有品質的生活